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(54) User context information database for plurality of network services 



(57) A service portal (1 ) enables services (4) to ac- 
cess to context information stored in a context database 
(5) by accessing a central access control unit (3) of the 
service platform (2). The access control unit (3) controls 
the access of the services (4) to the context database 
(5) according to access policies (15), which can be 
stored for example in a user profile database (6). 
The context database (5) get us information from 



basic sensors (1 0, 12) as well as from abstract sensors 
(11) processing context information from basic sensors 
(10, 12) and/or abstract sensors (11). Furthermore, a 
context deducing unit (7) deduces context based on 
context information already present in the context data- 
base (5) and supplies this back to the context database 
(5) for subsequent storing. The services of the service 
portal (1) therefore can access the context information 
in an easy and uniform way. 
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Description 

[0001 ] The present invention relates to a technique for 
accessing context information integrated in a service 
portal by means of multi-user data network, a computer 
software product for implementing such a services por- 
tal, a method for supplying context information to a con- 
text database as well as a computer software program 
for executing such a method. 
[0002] The general background of the present inven- 
tion is that small mobile devices will be used in the near 
future as the general means to access services any- 
where and anytime. Service are needed that exploit 
these technologies. A topic here is the access of mobile 
users to near-by services. Near-by services are services 
that exist in the same area as the user. The location of 
both the user and the services is the key aspect. As we 
will see, a location is often understood as a network po- 
sition. Having this point of view, ad-hoc technologies are 
a means to connect mobile users with services that exist 
in the network environment. Another interpretation un- 
derstands location as a geographical position. There- 
fore, location awareness technologies like global and lo- 
cal positional systems and digital models of the environ- 
ment offer a means to locate mobile users for location- 
aware-services. Location aware services are services 
that take into account the user's position in order to cus- 
tomise their service to a user. 
[0003] Generally services for mobile devices must be 
adapted to the current user situation. For instance cus- 
tomers require that the mobile telephone's call indica- 
tion might be issued to different means, e.g. through si- 
lent vibrations while being in a concert or through a di- 
rect flashing in a noisy environment. Other examples 
can be found through network features like call forward- 
ing, universal personal identification numbers, or voice 
mailboxes. The disadvantages of these mechanisms to- 
day are that the user must explicitly request the desired 
feature from a device or the connected network. 
[0004] Furthermore, the user must frequently check 
the status of different network settings. Usually he or she 
does not have intelligent means of automatically influ- 
encing these services. Why the described scenarios are 
mainly related to telecommunication issues, the same 
holds true for the currently emerging personalised serv- 
ices in the Internet. 

[0005] The described issues can be summarised un- 
der the phrase of context-aware services. A context- 
aware service exploits the abilities of future mobile de- 
vices to determine automatically or semi-automatically 
the current context of its user. Based on this information 
it adapts its services and behaviour to the respective us- 
er's needs including personal preferences in the envi- 
ronments capabilities. Furthermore it is possible that 
sensor units in the environment sense context about a 
user. Finally, sensors can exist neither in the user's de- 
vice nor in the current environment of the user, but be 
located elsewhere. 



2 

[0006] Common key issues associated with context- 
aware computing are: 

- when to collect and when to distribute context infor- 

5 mation, 

evaluate which information is central, 
how to effectively distribute this information (espe- 
cially in a mobile environment), 
to whom to distribute a context information, and 

w - how to deal best with the available information. 

[0007] EP 1030494 A1 of Sony International (Europe) 
GmbH discloses as a communication unit in the com- 
munication method with profile management The com- 

15 munication system thereby comprises a storage means 
for storing a profile database, that profile database com- 
prising parameter data describing attributes of the com- 
munication systems, the parameter data being arranged 
in parameter sets respectively describing a collection of 

20 attributes. The parameter sets are allocated to profile 
units so that each profile unit comprises at least one pa- 
rameter set and one parameter set can be allocated to 
a plurality of profile units. Furthermore managing means 
for managing that parameter data in the profile database 

25 and for controlling means for reading and writing param- 
eter data from and in said storage means are provided. 
[0008] EP001 04259.7 filed on March 01 , 2000 in the 
name of SONY INTERNATIONAL (EUROPE) GmbH 
describes a method and allows to have different user 

30 profile sets for different combinations of e.g. users, de- 
vices, network conditions, application situations etc. If 
for a certain combination no dedicated set of user profile 
data exists, then default profiles can be used. These de- 
fault profiles can be set per single user, devices etc. or 

35 per combination of these values. 

[0009] In view of the above-captioned prior art is the 
object of the present invention to facilitate the possibility 
of services to access context information. 
[0010] The subject is achieved by means of the fea- 

40 tures of the independent claims. The dependent claims 
develop further the central idea of the present invention. 
[001 1 ] Generally the services of a service portal shall 
be able to access context information integrated in the 
service portal in an easy and uniform way. The invention 

45 solves this problem by using a combination of a context 
unit and a service portal. This allows services of the por- 
tal to access to context information about an entity in a 
uniform way. Additionally the entity is able to control the 
access to its context information by the services. Finally 

50 the service portal can be used as one source of context 
information to be inserted in the context unit. 
[0012] According a first aspect of the present inven- 
tion therefore a service portal for accessing context in- 
formation integrated in the service portal by means of a 

55 multi-user data network is provided. The service portal 
comprises an access unit as a central entry point for dif- 
ferent services to access the common service portal. 
Furthermore, a context database is provided containing 
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context information of users of a service and connected 
to the access unit such that the context database is ac- 
cessible for the different services in a uniform and con- 
trollable manner. 

[0013] The access unit can have an access policy 
function to control the access of the context database 
by different services. 

[001 4] The access policies can be defined for groups 
of services and/or individually for each service. 
[0015] The access policies can have a default value 
for non-identified services. 

[0016] The access policies can be stored in a user 
profile database. 

[0017] The access unit can have an access monitor 
function generating an access log. This access log can 
be retrieved by the user. 

[0018] A service can query the context database for 
content in a request/reply interaction. 
[0019] Alternatively or additionally a service can reg- 
ister with the context database to be notified of changes/ 
updates of the content of the context database. 
[0020] The context database can be connected to a 
plurality of context sensors. 

[0021] The context sensors can comprise basic sen- 
sors as well as abstract sensors processing context in- 
formation of at least one other sensors (basic sensors 
and/or abstract sensors). 

[0022] The service portal can have a function to add 
or remove (dynamically) context sensors to/from the 
context database. 

[0023] The service portal can have a sensor configu- 
ration unit which can be accessed by the services to 
query the actual sensor configuration of the services 
portal. 

[0024] The service portal can have a sensor cata- 
logue which can be accessed by the services to query 
the sensors which can be configured at this service por- 
tal. 

[0025] The service portal can have a context deduc- 
ing unit deducing context information from the context 
information already present in the context database and 
for subsequent storage of the deduced context informa- 
tion in the context database. 

[0026] According to a further aspect of the present in- 
vention a computer software product for implementing 
a service portal is provided. 

[0027] According to a still further aspect of the present 
invention a method for supplying context information to 
a context database is provided. The context information 
represents information on the context of users in a multi- 
user data network. At first context information is gath- 
ered by basic sensors. The information of at least one 
basic sensors is then processed by an abstract sensor 
and supplied to the context database. 
[0028] An abstract sensor can furthermore process 
information of at least one other abstract sensor. 
[0029] On the basis of context information already 
present in the context database a further context infor- 



mation can be deduced and stored in the context data- 
base. 

[0030] Further features, advantages and objects of 
the present invention will become evident for the mans 
5 skilled in the art when reading the following detailed ex- 
planation of preferred and bodyments of the present in- 
vention and taking in conjunction with the figures of the 
enclosed drawings: 

io Figure 1 shows the integration of a service portal 
and a context database according to the present in- 
vention, 

figure 2 shows the configuration of a basic sensor, 

15 

figure 3 shows the configuration of an abstract sen- 
sor, 

figure 4 shows the units related to a context unit, 

20 

figure 5 shows the principal of a service platform, 
and 

figure 6 shows the relationship between applica- 
25 tions and a context architecture, wherein arrows in- 
dicate the data flow. 

[0031 ] With reference to figure 4 at first a context unit 
will be explained. A context unit is a logical entity that 
30 offer applications to access context data related to a sin- 
gle unit. This unit might be e.g. a mobile human user or 
a device or an application. Certain entities, the so-called 
sensors deliver context data to certain context units. 
[0032] As can be seen from figure 5 a service portal 
35 js a logical entity that offers users a single entry point to 
a number of services which share some knowledge of 
the user and which might interact to provide combined 
services (e.g. a calendar service that is able to send 
messages to a group of people of which addresses are 
40 stored in an address book services). Furthermore, a 
service portal can be a logical entity that offers services 
the possibility to be requested by users that use that por- 
tal and the possibility to use infrastructure means of the 
portal. A services portal may host only services operat- 
es ed by the portal operators or services operated by third 
parties and consists of service platform and services 
that use the platform. The services of a single portal can 
be accessed starting at a common starting point, e.g. a 
web page. 

so [0033] A service platform therefore consists of infra- 
structure components that support services offered at a 
certain service portal. This infrastructure includes hard- 
ware components, but also software components. Soft- 
ware components might comprise e.g. a user database, 

55 gateways to communication networks, units that allow 
output to the user to be adapted according to the used 
device etc. 

[0034] Service portals and context units insofar are 
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known general background. 

[0035] With reference to figure 6 a context technique 
will now be explained: The context technique presents 
an architecture that allows applications to uniformly ac- 
cess an open number of context sensors. This is 
achieved by a having a generic abstraction of a context 
sensor, the so-called context widget (see figure 6). Con- 
text widgets offer all the same interface to applications, 
such that the applications do not have to cope with the 
internals of accessing certain context information. Con- 
text servers allow to bundle context information which 
relate to a particular entity, e.g. a person. Context sen- 
sors offer the same interface as the widgets they bundle. 
The advantage of using context servers is that an appli- 
cation has only to interact with one entity instead of all 
the context widgets. Finally, interpreters allow to deduce 
information out of a number of context information pro- 
vided by an application or context widget. The deduced 
information can then be returned to the component (e. 
g. application or widget) that called the interpreter. 
[0036] Figure 1 shows the general structure of a serv- 
ice portal according to the present invention. The differ- 
ent services 4 can access a service platform 2 of the 
service portal 1 by means of a coming entry point, e.g. 
an access control unit 3. The access control unit 3 con- 
trols the access of the different services 4 to a sensor 
catalogue 9, a sensor configuration unit 8 and a context 
database 5. The function of these different elements of 
the service platform 2 will be explained later on. 
[0037] A service portal according to the present inven- 
tion can also be referred to as Context-aware Mobile 
Portal (CAMP). 

[0038] The access control unit 3 allows the different 
services 4 or groups of services 4 access to the context 
database 5, the sensor configuration unit 8 and the sen- 
sor catalogue 9 according to an access policy 15 of a 
user management system 14. Particularly, the access 
policy 15 of the user management system 14 can be 
stored in a user profile database 6. 
[0039] The user profile database 6 supplies informa- 
tion to the context database 5 as well as to the sensor 
configuration unit 8. Furthermore, the sensor configura- 
tion unit 8 and the sensor catalogue 9 exchange infor- 
mation. 

[0040] The context database 5 gathers context infor- 
mation from different sensors 1 0, 1 1 , 1 2 as well as from 
a context deducer 7. The context deducer 7 deduces 
additional higher-order context information on the basis 
of the context information already present in the context 
database 5, wherein the higher order processed context 
information is then stored again in the context database 
5. 

[0041 ] The different context sensors 10,11,12 collect 
context information such as: 

The location of the user, 

date and time at the location of the user, 

the temperature at the location of the user, 



personal user data like his/hers schedule, 

- the history of his/hers service usage, 

- the actual condition of the network the user con- 
nects to, 

5 - the actual condition of the user device, 

the user profile (e.g. age, gender, nationality and us- 
er preferences), 
the abilities of the user device, 
the social situation the user currently experiences. 

10 

[0042] These collected context information is send to 
a context server, wherein according to the architecture 
of figure 1 a context database 5 is used as context serv- 
er. The sensors 10, 11, 12 offer a generic interface to 

15 the context server (context database 5). 

[0043] As can be seen from figure 1 , there are two 
different main types of sensors. Basic sensors 10, 10', 
1 0", 12,12' sample data such as f .e. the location of the 
device or the schedule of a human user. Basic sensors 

20 might be attached to an entity (user device 13) about 
which context data is collected (see basic sensor 12'). 
An example for such a basis sensor 1 2' is a GPS sensor 
that sense the position of a user device 13. Other basic 
sensors 1 2 can be part of the physical environment, thus 

25 sensing environmental data (like the temperature, or the 
location of a mobile device, "tracking systems"). 
[0044] Finally, basic sensors 10" might be located 
elsewhere sensing context data like the schedule of the 
user. These basic sensors might be part of the service 

30 portal or can be located outside the services portal (ba- 
sic sensors 10,1 0'). To insert user context data that ex- 
ists in the service portal 1 for administrative reasons (e. 
g. user profile data of the user profile data base 6 and 
the service usage history) normally, basic sensors 1 0" 

35 are used and are connected to the corresponding serv- 
ice portal components. 

[0045] The context data can be inserted directly into 
the context data base 5, but often, the data of a number 
of basic sensors is compiled and processed in a hierar- 

40 chy of abstract sensors 1 1 that finally feed the thus proc- 
essed higher-order context information to the context 
database 5. Abstract sensors 11 are therefore compo- 
nents of the service platform 2 that are able to process 
data of a number (one or more) of other sensors (either 

45 basic sensors or other abstract sensors) , thus producing 
context data sent as an higher order information to the 
context database 5 and stored therein. From a view 
point of the context database 5, also abstract sensors 
1 1 are sensors they offer the same generic interface as 

50 the other (basic) sensors. One example of an abstract 
sensor 11 is a "Location Manager" that collects informa- 
tion about the position of a user from different sources, 
selects "better" sources and combines the information 
of different sources, thus generating a more accurate 

55 user position. 

[0046] Some context information is not sensed, but 
deduced by a context deducer 7 from some information 
already present in the context database 5. A social sit- 
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uation deducer, e.g. determines whether a user is in a 
meeting by searching the schedule information in the 
context database 5. A transmission cost deducer might 
e.g. determine that the power sent to the user has to be 
reduced due to the fact that the user calls from overseas 
and that the transmission costs therefore are high. As 
the result is also context information, a context deducer 
7 inserts the deduced information again in the context 
database 5 for storage. 

[0047] Due to the access control unit 3 different serv- 
ices 4 can access the data stored in the context data- 
base 5 in a controllable and uniform manner. There are 
two ways to access such data. First, a service 4 can que- 
ry the context database 5 for values (e.g. by using a key 
to get values), which are then returned to the service 4. 
This is called request-reply interaction mode. According 
to a second mode a service 4 can subscribe itself at the 
context database 5 for changes and/or updates of cer- 
tain fields of the context database 5. In case of such a 
change, the context database 5 then sends the new (up- 
dated) values to the corresponding service 4. The mode 
is known as publish-subscribe interaction. 
[0048] Services 4 cannot only query context data from 
the context database 5, but can also be able to insert 
date into the context database 5. (A service might e.g. 
want to add the name of a file to the context of a user 
which has accessed a file lately). 
[0049] An important issue is the control of the access 
to the context datastore and the context database 5. As 
often context data are privacy sensitive information, the 
access to such kind of data by services 4 has to be con- 
trollable, especially in the case of context data relating 
to human users. This access comprises read and write 
access to context data. Therefore access policies 15 
can be specified describing which service 4 is able to 
get access on which context information and in which 
way. In order to prevent the user from specifying a lot of 
details in a such access policy 15, the context data can 
be grouped, so access statements can relate to a whole 
group of context data. The controlling entity, the access 
controlling unit 3, is additionally able to specify a default 
access policy 15, so it does not need to specify policies 
for every group of services and/or context data in the 
context database. 

[0050] As new sensors might introduce new context 
data into the context database 5 and as new services 
might be installed at the service portal 1 , there might be 
a need for extending the access policies 15. is one way 
to cope with that situation is the usage of default policies 
as described. As the access policy is part of the user 
profile information, also this policy can be stored in the 
user profile database 6. 

[0051] To allow the user to monitor the accesses to 
his/her context by services 4, the context access control 
unit 3 maintains an access monitor (not shown in figure 
1 ) generating an access log. The user can then read the 
entries of this log to survey the context accesses of the 
different services 4. 



[0052] In the following the configuration process of the 
sensor hierarchy will be explained with reference to fig- 
ures 2 and 3. 

[0053] In order to deliver data to the context database 

5 5, the sensor hierarchies have to be configured, i.e. es- 
tablished and logically connected. The configuration 
takes place if an entity (normally a component of the 
service platform 2) decides to start to a sensor. If this 
sensor is a basic sensor 10, 12, the sensor is simply 

10 connected to the context database 5 (see figure 2). If 
this sensor is an abstract sensor, the sensor is estab- 
lished. If this sensor uses a hierarchy, this hierarchy is 
configured until finally all used basic sensors 10, 12 are 
connected to the corresponding abstract sensor 11 . Fi- 

15 nally the top level abstract sensor 1 1 is connected to the 
context database 5 (see figure 3). The configuration is 
done by means of a sensor figuration unit 8 (see figure 
1 ), which is a component of the services platform 2. 
[0054] Sensors can be distinguished according to the 

20 period they shall deliver data to the context database 5. 
Some sensors shall always deliver data, even if the user 
is not connected to the service portal 1 . This might be 
the case e.g. for location information. Other sensors 
shall be active only during the period the user is con- 

25 nected to the service portal 1 (e.g. in the case of a user 
profile sensor). Finally, a third group of sensors shall be 
used only during certain periods of the time duration the 
user is connected to the network. Additionally, a service 
4 that is installed at the service portal 1 may ask the 

30 service platform to configure a new sensor. The service 
can inform itself about the sensors that can be config- 
ured at this service portal 1 by consulting a sensor cat- 
alogue unit 9 connected to the sensor configuration unit 
8. The sensor catalogue unit 9 is another service plat- 

35 form component, which can be accessed by the access 
control unit 3. 

[0055] When services are started, they might want to 
learn about the actual sensor configuration in order to 
select context data to be use. To that end, services can 

40 query the sensor configuration unit 8 by an access by 
means of the access control unit 3. After a service has 
been started, it might be the case that new sensors are 
connected to the service platform 2 or that existing sen- 
sors are disconnected (e.g. in case of a technical fail- 

45 ure). In this case the services 4 have to be informed 
about the change. This can be done either when the 
services ask for context data from a disconnected sen- 
sor. In this case a special error message is returned. If 
the service has subscribed for that data, a message can 

50 be submitted that state the disconnection of the sensor. 
In the case of a new sensor, services 4 can be informed 
using a message by the service platform 2. In this case, 
the service platform 2 automatically issues a new sensor 
instalment message to registered services 4. Some sen- 

55 sors of hierarchy might change over time, e.g. in the 
case of location sensors installed in a building (tracking 
system) the sensor depends on the position of a user. 
These changes are handled by abstract sensors 11, 
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which hide this dynamics from the context database 5. 
The exact mechanisms that allow appearing and disap- 
pearing of basic sensors 10, 12 to communicate with 
abstract sensors 1 1 depend on the nature of the context 
data. 

[0056] Examples of services 4 using the aforemen- 
tioned architecture are e.g.: 

location services that are able to display the current 
location of a certain user, 

projecting services that select video projectors ac- 
cording to the room the user is currently located at, 
services that adapt their output according to the cur- 
rent context of the user, e.g. the device used, the 
network condition, the location of the user etc., and 
background lit display that use a service to deter- 
mine the light level at the current position of the user 
in order to adapt the light level of the display. This 
results in brighter displays used outside during the 
night and no background lit in bright rooms. 

[0057] In the following some typical processes per- 
formed in connection with the present invention will be 
explained: 

[0058] A context value is entered into the context da- 
tabase 5: 

When the context changes (e.g. before the user is mov- 
ing), and a context sensor 10, 11, 12 senses such a 
change, the corresponding basic sensor 10, 12 sends 
a message to the next sensor in the hierarchy (if any). 
This sensor can be an abstract sensor 11 and can use 
this data to compute a value that is sent to the next sen- 
sor and so on until the top level sensor is reached. This 
top level sensor sends the value to the context database 
5 where it is stored under a certain key- In case there is 
a service 4 that has subscribed for that key, the context 
database 5 generates a message containing the key 
and the value to that service. 

[0059] A service 4 requests a context database value: 
If a service requests a value from the context database 
5, the access control unit 3 checks whether there is an 
access policy 15 that allows or prevents this access. 
This check is therefore effected dependent on the kind 
of service and the kind of context data requested. There- 
fore the kind of service as well as the kind of context 
data are parameters of the access policy. If the check is 
positive, the corresponding action is taken. If not, the 
access control unit 3 checks whether there is an default 
policy that can be applied. If so, the corresponding ac- 
tion is taken. If not, and the concerned entity is not a 
human user, the request is denied. If not, and the con- 
cerned entity is a human user, the answer is postponed 
until the user was asked for a decision, which is then 
applied. Therefore in the last case the user has the pos- 
sibility to decide himself whether he wants the service 
4 to access the corresponding context data or not. 
[0060] A service wants to subscribe for a certain con- 
text database key: 



In this case the above explained mechanism for a re- 
quest is applied, but this time concerning the subscrip- 
tion, not the request of the value. If the access control 
unit yields a positive answer, the checking process does 

5 not have to be done for every publication of a value. 
[0061] The present invention therefore has the advan- 
tages, that using the context information, the services 4 
of a service portal 1 are able to adapt the service provi- 
sioning and the presentation to the user accordingly. 

10 The more context a service 4 can access, the better the 
service can adapt to the current situation of the user. 
[0062] Providing some context information or com- 
bined context information itself is a service 4 that can 
be offered to the user of a service portal 1 . Therefore, 

15 services 4 that provide this information can be created 
more easily. 

[0063] As the context infrastructure is offered by the 
service portal 1 to all services 4, these services 4 do not 
have themselves to select a context mechanism and to 

20 discover context servers (such as for example the con- 
text database 5 of the present invention). 
[0064] Context information about a user that already 
exists (e.g. the user's preferences) in the service portal 
1 , can be used by the context server (context database 

25 5). Therefore, also these information can be gathered 
like other context information by the services 4 as a uni- 
form way. 

[0065] The context server mechanism allows an entity 
to control the access to the context information by serv- 

30 ices. The described invention particularly allows for dy- 
namically adding new and removing existing sensors to 
a context server (context database 5). 
[0066] Finally, the described invention allows units to 
use and process the data of a number of sensors before 

35 entering it into the context server (context database 5). 



Claims 

40 1 . Service portal for accessing context information in- 
tegrated in the service portal by means of a multi- 
user data network, comprising: 

an access unit (3) as a central entry point for 
45 different services (4) of the network to access 

the common service portal (1), and 
a context database (5) containing context infor- 
mation of users of a service and connected to 
the access unit (3) such that the context data- 
50 base (5) is accessible for the different services 

(4) in an uniform and controllable manner. 

2. Service portal according to claim 1 , 
characterized in that 

55 the access unit (3) has an access policy function 
(15) to control the access of the context database 
(5) by the different services (4). 
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3. Service portal according to claim 2, 
characterized in that 

the access policies (15) can be defined for groups 
of services and/or individually for each service. 

4. Service portal according to claim 2 or 3, 
characterized in that 

the access policies (1 5) have a default value for not 
specified services. 

5. Service portal according to anyone of claims 2 to 4, 
characterized in that 

the access policies (15) can be defined for groups 
of context data in the context database (5). 

6. Service portal according to anyone of claims 2 to 5, 
characterized in that 

the access policies (15) are stored in a user profile 
database (6). 

7. Service portal according to anyone of the preceding 
claims, 

characterized in that 

the access unit (3) has an access monitor function 
generating an access log. 

8. Service portal according to anyone of the preceding 
claims, 

characterized in that 

a service (4) can query the context database (5) for 
content in a request/reply interaction. 

9. Service portal according to anyone of claims 1 to 7, 
characterized in that 

a service (4) can register with the context database 
(5) to be notified of changes of the content of the 
context database (5). 

10. Service portal according to anyone of the preceding 
claims, 

characterized in that 

the context database (5) is connected to a plurality 
of context sensors (10, 11, 12). 

1 1 . Service portal according to claim 1 0, 
characterized in that 

the context sensors comprise basic sensors (10, 
1 2) as well as abstract sensors (1 1 ) processing con- 
text information of at least one other context sensor. 

12. Service portal according to claim 10 or 11 , 
characterized by 

a function to add or remove context sensors (10,11, 
12) to/from the context database (5). 

13. Service portal according to anyone of claims 10 to 
12, 

characterized by 



a sensor configuration unit (8) which can be ac- 
cessed by the services (4) to query the actual sen- 
sor configuration of the service portal (1). 

5 14. Service portal according to anyone of claims 10 to 
13, 

characterized by 

a sensor catalogue (9) which can be accessed by 
the services (4) to query the sensors (10, 11, 12) 
10 which can be configured at this service portal (1 ). 

1 5. Service portal according to anyone of the preceding 
claims, 

characterized by 

15 a context deducing unit (7) deducing context infor- 
mation from the context information already present 
in the context database (5). 

1 6. Service portal according to anyone of the preceding 
20 claims, 

characterized in that 

services (4) can insert information in the context da- 
tabase (5) by means of the access control unit (3). 

25 17. Computer software product for implementing a 
service portal according to anyone of the preceding 
claims. 

18. Method for supplying context information to a con- 
30 text database, 

wherein the context information represents infor- 
mation on the context of users in a multi-user data 
network, 

the method comprising the following steps: 

35 

gathering context information by basic sensors 
(10,12), 

processing the information of at least one basic 
sensors by an abstract sensor (11), and 
40 - supplying the processed information of the ab- 
stract sensor (11) to the context database (5). 

19. Method according to claim 18, 
characterized in that 

45 an abstract sensor (11) furthermore processes in- 
formation of at least one other abstract sensor (11). 

20. Method according to claim 18 or 19, 
characterized in that 

50 on the basis of context information already present 
in the context database (5), further context informa- 
tion is deduced (7) and stored in the context data- 
base (5). 

55 21. Computer software program for executing a method 
according to anyone of claims 1 8 to 20 when run on 
a computing device. 
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